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Saludo a los viejos amigos 


ste es el primer número de 
la nueva Rendermanía. Sus 
objetivos no difieren dema- 
siado de los de la antigua 
sección del mismo nombre. 
Desde estas páginas confia- 
mos en poder presentaros 
mes ames las novedades del mundillo in- 
fográfico, en exhibir las escenas creadas 
por los mejores artistas y en hablar de 
las técnicas utilizadas para crear di- 
chas escenas. 

Aquí se hablará de POV. Polvray, 
Imagine y de otros programas ya cono- 
cidos por el lector. Estudiaremos el fun- 
cionamiento de programas nuevos. de 
herramientas diversas como modelado- 
res, generadores de fractales, converso- 
res de formatos, etc. y crearemos nues- 


tras propias imágenes con dichas tools. 


Todos estos contenidos se expondrán 
en varias secciones. Estas serán bas- 
tante flexibles, con un número variable 
de páginas y la posibilidad de irse al- 
ternando unas a otras en cada número. 
Además ocasionalmente se preparará 
algún que otro número monográfico. 
Ahora veamos lo que el lector puede 
esperar de la nueva Rendermanía. 


La printera página será siempre una 
imagen creada por técnicas infográfi- 
cas. Normalmente esta imagen habrá 
sido creada ex-profeso para ser utiliza- 
da como portada y los entresijos de su 
diseño y creación serán desvelados en 
una sección llamada precisamente así: 
“La Portada” 
da se empleurá cualquiera de los pro- 


. Para realizar esta porta- 


gramas de generación de imagen sinté- 
tica tratados en Rendermanía. De esta 
manera dicha portada nos servirá para 
ilustrar un caso práctico de planifica- 
ción y desarrollo de una escena; aparte 
de para estudiar los detalles propios del 
trabajo con las herramientas emplea- 
das. La página o páginas siguientes es- 
tarán ocupados por “La ventana”, una 
sección dedicada a presentar noticias, 
rumores y novedades. 
Otra sección clave es “Cómo...” 

Esta frase se completará con textos ta- 


“ 


les como “...exportar modelos para 
POV”.“...crear superficies de revolu- 
ción con Imagine”, etc. En cada núme- 
ro de Rendermanía habrá una o dos 
secciones encabezadas de esta manera 
y dedicadas a tratar en detalle diver- 
sas cuestiones prácticas. 

“El taller virtual”, por otra parte, se- 
rá una sección dedicada a tratar aspec- 
tos más especulativos y algo más teóri- 
cos. Aquí podremos, por ejemplo, 
hablar sobre cómo solventar las limita- 
ciones de tal o cual herramienta para 
crear algún objeto o efecto dado. Tam- 
bién pueden compararse aquí los distin- 
tos métodos para crear texturas proce- 
durales con programas diferentes, etc. 


Los casos prácticos de creación y/o. 


uso de modelos serán tratados, en “Bi- 
blioteca 3D”. Estos modelos general: 
mente serán los creados para compo- 
ner muchas de las € esc qn 
Ml 
Los aspectos de elainfogr 
nados con la p. 
la sol pixels > 
cual los par a la pr o 
fica encontri -ulos 


con el sarrollo de utilidade 


POVy otros prog 1bié 
tarán aquí te sh tales 
aplicación, de pur gl 

xels, los h oles md , € ac Po Ú 

de de pra progra 

' > ión de EN 

escenas. Apart de ¡o Skod esto apar 

rán de tanto ensanto infor 


de Rendermanía. 


también se ha 
orientada 


secciones sobre las or hora no 
vamos a dar detalles, Confiamos en que 
este primer número -casi:enteramen 
dedicado a POV puesto que en el ante- 
rior falto espacio para abordar algunos 
temas-, sea de vuestro agrado. 

Además, todos vosotros tendréis un 
espacio permanente en Rendermanía 
dentro del Foro del lector, apartado | 
donde aparecerán vuestras creaciones, 


preguntas, sugerencias y críticas. 
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En las escenas 
medievales del número 
anterior de 
Rendermanía se echaba 
en falta un importante 
detalle, la gente. En 
efecto, en una escena 
espacial o en una 
imagen de una fábrica 
automatizada las 
personas no son 
imprescindibles. En una 
ciudad medieval, en 
cambio, el espectador 
puede acabar 
preguntándose si la 
escena no habrá sufrido 
los efectos de algún 
tipo de peste negra 


virtual. 


esgraciadamente el 
lenguaje escénico 
de POV no ha sido 
diseñado para crear 
formas orgánicas. 
En teoría puede re- 
sultar posible crear formas vivas a golpe 
de CSGs, pero, en la práctica, esto es in- 
viable. Otra posibilidad radica en el uso 
de las blobs. En efecto. existe un mode- 
lador que, en teoría, es a POV lo que Me- 
tareyes es a 3D Studio. Sin embargo es- 
ta idea tampoco parece muy práctica ya 
que las blobs están entre los objetos 
más lentos de calcular en el lenguaje es- 
cénico de POV y una forma humana re- 
queriría docenas, quizá cientos de blobs. 


Decisiones 
Para poblar las ciudades virtuales de 


estas escenas. el autor de estas líneas to- 
: mó tres decisiones: crear un caballero 
: acorazado —para ahorrarse el engorroso 
¿ trabajo de modelar ciertas partes comple- 
¿jas como el rostro-, caricaturizar al per- 


sonaje —así puede tener las proporciones 


¿ que nos venga en gana— y emplear un 
¿  modelador para usar herramientas de di- 


seño de las que POV aún no dispone. 


La caricatura 
El primer paso para crear cualquier 
modelo es siempre realizar un par de 


¿ esbozos en papel para conseguir una 


idea clara de su forma y proporciones. 
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Hay que dibujar al modelo en dos vis- 
tas: una frontal y otra de perfil. Los es- 
bozos también nos servirán para divi- 
dir el modelo en las diferentes piezas 
de que va a estar compuesto y para pla- 
nificar la forma en que vamos a cons- 
truir dichas piezas y, por supuesto, la 
herramienta que vamos a emplear. 

Hecho esto el siguiente paso era el 
propio modelado del personaje. Para 
esto, aunque la versión 3.0 puede crear 
objetos extrude y superficies de revo- 
lución, el lenguaje escénico de POV no 
era demasiado práctico. Téngase en 
cuenta que muchas de las piezas del lan- 
cero son objetos que debían construirse 
mediante deformaciones o extrusiones 
de dos vistas distintas; algo que puede ha- 
cerse con programas como 3D Studio, 
Imagine, Amapi, Caligary y otros, pero 
que POV aún no puede hacer. —el lenguaje 
essénico. de POWeestá más orientado a la 
construcción de objet0s como nayes o edi- 
ficite=, Hoy nO'vamos ."explica”el pro- 
ceso de modelado de nuestro personaje 
Esto quedara para el futuro, cuando ex- 
pligueros el funcionamiento de algún 
buen modelador. Hoy tan solo nos inte- 
res estudiar los pasos precisos para ex- 
portar un modelo creado gon alguna de 
estas herramientas a POV. 


Colocación espacial 

El primer problema con el quedebe 
enfrentarse el artista que quiere exportar 
a POV modelos creados desde un'mo- 
delador, es que la orientación de log ejes 
en el modelador no tiene por qué ser la 
misma que emplea POV. Y lay dimen- 
siones del personaje tampoco tenen por 
qué coincidir con las delos modelos 
creados con el lenguaje escenico. Sien- 
do así, ¿cómo nos las apañaremos pára 
siluar a muestros personajes sobre el sue 
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lodenuestras pov-es- 
cenas? ¿Y cómo les 
daremos las dimen- 
siones adecuadas? 

Estudiemos pri- 
mero la orientación 
y colocación del 
personaje. Todos los 
modeladores suelen 
usarr varios planos 
de construcción con 
distintas vistas para 
el proceso de mode- 
lado. Si la orienta- 
ción de los ejes en el 
modelador comcide 
con la de POV, no 
tendremos que preo- 
cuparnos de reorien- vida con la 
tar al personaje y 
bastará con situar a 
éste sobre el suelo 
de POV y escalarlo. 
En POV, la mayoría 
de los usuarios aceptamos como suelo el 
plano formado por los ejes X-Z. Este sue- 
lo está colocado a una altura O en el eje Y 
en nuestras escenas medievales. Quere- 
mos colocar al personaje con los pies so- 
bre este suelo, colocando su centro de gra- 
vedad en el eje Y, y situándolo de frente a la 
cámara, ala que suponemos en algún pun- 
to del lado negativo del eje Z. Llamaremos 
a esto la pov-or¡entación. 

Si en el'modelador la orientación de 
ejes y el plano de construcción usado es 
el mismo no habrá ningún problema, pe- 
ro veamos un caso algo más complejo: 
el de 3D Studio, donde los ejes Z e Y 
están intercambiados respecto a los de 
POV?En este caso. para conseguir dar al 
persdinaje la pov-orientación adecuada, 
habremos de colocar al lancero de pie y 
mirando hacia nosotros en la ventana 


Nuestra ciudad 
medieval cobra 


presencia de este 
grupo de lanceros. 


Top. Además, en la ventana Left, el lan- 
cero estará colocado de perfil, con los pies 
y la cabeza formando una línea horizontal 
paralela a la de la ventana, con el casco 
apuntando hacia el lado izquierdo de la 
ventana y los ojos mirando hacia abajo. 
Una vez lograda la pov-orientación 
hay que colocar los pies del lancero en 
el suelo y centrarlo en las coordenadas 
<0,0> del eje (sea cual sea) que aban- 
dona perpendicularmente dicho suelo. 
(Aquí ya el caso es general, para cual- 
quier modelador). Para ello lo mejor es 
dibujar en el modelador una superficie 
que sirva como pov-suelo. O sea, crea- 
remos una superficie perpendicular al 
lancero y la situaremos en el punto 0 
del eje en que la línea pies_cabeza es 
paralela. Esta superficie que puede ser 
uno de los lados de una caja— representa 


el suelo de POV. Cuando tengamos la ca- 
ja arrastraremos al lancero hasta deposi- 
tar sus pies sobre el “pov-suelo”. Hecho 
esto debemos centrar al personaje con el 
eje en que la línea pies-cabeza de éste es 
paralela. Para ello, si es necesario, pode- 
mos crear otra caja. Hecho todo esto, tan 
sólo resta escalar al personaje. 


Escalas 

En nuestras escenas medievales la 
unidad de medida elegida ha sido el de- 
címetro. Las puertas empleadas para 
las casas y las torres, por ejemplo, tie- 
nen una altura de unas 20 unidades in- 
cluyendo el marco. Esto significa que, 
desde el modelador, habremos de esca- 
lar al personaje de modo que la distan- 
cia ples-casco sea holgadamente infe- 
rior a 20 unidades. Como los pies del 


personaje están a 
O unidades del 
plano del suelo, 
podremos escalar- 
lo tranquilamente. 
El cambio de es- 
cala se efectuará 


en el suelo y cen- 
trado. Ni que de- 
cir tiene que la 
operación deberá 
ser global, en los 
tres ejes. Hecho 
todo esto, tan sólo 
nos resta eliminar 
las cajas y grabar 
un fichero con el 
modelo. 


Conversión 
de formatos 
Ya tenemos un ar- 
chivo con un mo- 
delo con la escala y orientación ade- 
cuadas para incluirlo en nuestras 
escenas medievales. ¿Y ahora qué? El 
formato del fichero no será, de seguro, 
comprendido por POV, ya que éste 
precisa que los modelos se almacenen 
en un fichero ascii empleando senten- 
cias del lenguaje escénico. Afortuna- 
damente POV deja una puerta abierta a 
la importación de modelos poligona- 
les. Esta puerta son las sentencias 
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dejando al modelo : 


triangle y smooth_triangle que pueden 
utilizar los programas de conversión 
para crear ficheros “traducidos” par- 
tiendo de archivos eh otros formatos. 
Herramientas como Wevt2pov ó 
3ds2pov generan ficheros ascii para 
POV partiendo de archivos que em- 
plean el formato de 3D Studio, Imagi- 
ne y otros programas. Estas tools pue- 
den encontrarse fácilmente (han sido 
distribuidas por Pcmanía) y son de un 
uso muy sencillo. 

Una vez que tenemos el fichero tra- 
ducido hay que tomar nota de algunos 
detalles. El primero es que lo que te- 
nemos es una “estatua” con una postu- 
ra determinada del personaje. Si dese- 
amos más estatuas, habremos de 
regresar al modelador, hacer adoptar al 
personaje la postura deseada y repetir 
todo el proceso utilizando otro nombre 
para el fichero. Otra cuestión impor- 
tante es que las herramientas de tra- 
ducción de formatos 3D no suelen tra- 
ducir las texturas y, de ser éste el caso, 
no suelen aplicar bitmaps. Por ello lo 
mejor será usar colores para los perso- 
najes y aplicar las texturas desde POV. 

Por último debe existir un identifica- 
dor que sea igual a la unión de todas los 
objetos que componen al personaje. S1 
éste identificador no existe deberemos 
crearlo nosotros mismos trasteando en 
el archivo traducido con un editor de 
texto. ¡Ojo! Los ficheros con modelos 
poligonales suelen ser bastante gran- 
des, de 1 megabyte o más. Habrá que 
usar un editor que pueda manejar ar- 
chivos de este tamaño (el edit de Dos 
no sirve). Una vez que tengamos un 
identificador para designar al modelo 
importado podremos emplear a éste en 
la escena tantas veces como queramos 
(véase el ejemplo de desfile .pov). 
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Problemas con Bitmaps 


Ya hemos estudiado, en 
el pasado número, un 
caso concreto de 
aplicación de texturas 
bitmap sobre los 
modelos usados para 
componer las pov- 
ciudades medievales. 
Hoy profundizamos 
8 mismo tema, 
estudiando diversos 
problemas relacionados 
con el uso de bitmaps 
en los objetos creados 


conPOV. 


unque las texturas : 


procedurales resul- : 
tan ideales para ¿ 
crear objetos con : 
apariencia de ma- ¿ 
dera, piedra, metal : 
y de otros tipos, tendremos serias difi- ¿ 
cultades en otros casos. Así, aunque en : 
la versión 3.0 de POV se incluye un ¿ 
nuevo patrón llamado brick (ladrillo). E 
nos resultaría muy difícil construir con E 


él una textura de apariencia similar a 
las empleadas para las paredes de las 
casas y muros del castillo. 


El problema fundamental 
Existen algunas diferencias funda- 
mentales entre las texturas procedura- 
les y los bitmaps. Las primeras son 
construidas por el usuario usando las 
sentencias disponibles para ello en el 
lenguaje escénico mientras que los bit- 


maps son mapas de imagen, en formato 
tga, gif u otros, con los que recubrire- 


mos los objetos de la misma forma que . 


si los envolviéramos con un papel pin- 
tado. Las texturas procedurales, por el 
contrario, basándose en los parámetros 
suministrados por el usuario en las sen- 
tencias de patrones, distorsión de tra- 
mas, pigmentación, etc., emplean mé- 


todos algorítmicos para construir : 


invisibles bloques tridimensionales que 
impregnan todo el volumen espacial de 
los objetos sobre los que se aplican. 
Así, si aplicamos una textura algorít- 
mica de madera sobre un cubo y reali- 
zamos después una operación CSG de 
recorte sobre él, observaremos que el 
interior del objeto también tiene los 
anillos y la apariencia de la madera. 
Esta aplicación tridimensional de las 
texturas procedurales es una caracterís- 
tica muy útil, ya que nos deja las ma- 
nos libres para concentrarnos en la 
construcción de los objetos. Sin embar- 


go, aunque POV dispone de una buena : 


librería de texturas de este tipo, puede 


ocurrir que no exista ninguna similar a 


la que precisamos en ese momento. En 
este caso sólo tendremos dos alternati- 
vas: crear nuestra propia textura algo- 


rítmica usando las sentencias de POV o : 


bien utilizar un bitmap. La primera al- 
ternativa puede ser o muy sencilla o 
bien extraordinariamente difícil, de- 
pendiendo de lo que pretendamos lo- 
grar. En el caso de los muros de las ca- 
sas y torres medievales, el que esto 
escribe optó por utilizar un par de bit- 
maps. 


Distintos ejemplos de 
aplicación de bitmap 
sobre un mismo 
elemento. 


Aplicación de bitmaps 

Aunque ya hemos comentado los as- 
pectos básicos de la aplicación de bit- 
maps en POV, volveremos hoy sobre el 
tema ya que ha afectado de modo directo 
a la forma en que se han construido los 
objetos sobre los que habían de aplicarse 
estas texturas. También veremos algunos 
fallos de aplicación que quizá no fueron 
advertidos en las escenas del número an- 
terior, ya que la cámara había sido colo- 
cada a una cierta (y prudente) distancia. 
En el número anterior de Rendermanía 
se explicó el formato de la sentencia ima- 
ge_map, con la que el usuario puede apli- 
car un bitmap sobre el objeto eligiendo 
el tipo de aplicación a que va a recurrirse 
para efectuar la “envoltura”. Recordemos 
que podíamos escoger entre 4 posibles t1- 
pos de recubrimiento dando diferentes 
valores al modificador map_type; mape- 
ado plano (0), esférico (1). cilíndrico (2) 
y toroidal (5). Así, en las sentencias... 


pigment(image_map(tga “textl tga” map_type 0] scale <14,14,1>) 


..-se especifica que la textura “text]”, 
en formato tga, recubrirá al objeto con 
un mapeado de tipo plano. Por defecto 
la textura se extiende siempre sobre un 
área que va desde las coordenadas 
<0,0> hasta <l,1> en el plano X-Y y se 
repite cuantas veces sean precisas para 
cubrir totalmente el objeto (a menos que 
incluyamos la palabra “once”). Como 
este área de aplicación suele resultar 
inadecuada con respecto al tamaño del 
objeto, suele indicarse también un fac- 
tor de escala para la textura en los ejes 
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De izquierda a 
derecha: aplicación 
en el plano 
estandar, rotada en 


dos ejes y sobre 


dos objetos. 


X e Y sobre los que el bitmap, por de- 
fecto, se aplica. 

Los dos bitmaps empleados se apli- 
caron en estas escenas sobre todos los 
objetos que habían de exhibir una apa- 
riencia de roca, como paredes, escale- 
ras, torreones, etc. En todos los objetos - 
incluso en los de forma esférica-, el tipo 
de aplicación elegida fue la planar (lue- 
go veremos por qué). Comenzaremos 
estudiando un caso de mala aplicación 
de uno de estos bitmaps sobre un objeto. 


El bitmap determina la forma 

En castlib (la librería escrita para 
crear escenas de construcciones medie- 
vales) hay varias escaleras de distintos 
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tamaños. Algunas se emplean para ac- 
ceder a las murallas y otras sirven para 
llegar hasta la puerta del segundo piso 
de algunas casas. Todas las escaleras 
están construidas de la misma forma; 
mediante una unión de cajas que hacen 
las veces de peldaños. La escalera está 
orientada lateralmente con respecto al 


eje Z. Mirando desde el lado negativo 
de este eje veremos como los peldaños 
ascienden hacia el lado izquierdo de la 
pantalla. En este objeto el bitmap se 
aplicó inicialmente en el plano por de- 
fecto con lo que la aplicación resulta 
correcta en las caras laterales de la es- 
calera. No ocurre así en cambio con la 
parte superior, donde parece como si 
los pixels correctamente aplicados en 
el lateral se estirasen a lo largo del ob- 
jeto, en el plano de aplicación, lo cual 
es precisamente lo que sucede en el 
mapeado plano (véase la escena). Si 
para solucionar esto rotamos 90 grados 
el plano de aplicación para que la tex- 
tura se aplique sobre el plano X-Z, no 


a Y 


ganaremos gran cosa ya que en dicho 
caso el bitmap quedará bien aplicado en 
la parte superior de la escalera y mal en 
los laterales de la misma. De esto dedu- 
cimos que si el plano de aplicación tie- 
ne unos 90 grados con respecto a una 
superficie del objeto, los pixels que co- 
rrespondan en la textura se “estirarán” 
para cubrir toda esa superficie. 

Una solución para esto residiría en ro- 
tar el plano de aplicación de modo que 
haga ángulo con todas las superficies del 
modelo. Sin embargo esto también tiene 


sus pegas. Si deseamos que la aplicación : 


de la textura resulte sin inclinaciones en 
todas las superficies del modelo, no ten- 
dremos más remedio que aplicar la tex- 
tura más de una vez. Sin embargo esto, 
colocar dos o más sentencias pigment]), 
no dará el resultado esperado. 

La única salida que nos queda es rees- 
eribir el modelo de forma que se tengan 
en cuenta las peculiaridades del mapeado 
plano. Para ello dividiremos el objeto en 
tantas piezas como planos de mapeado 
vayamos a aplicar sobre él. En el caso de 
las escaleras estableceremos, en princi- 
pio dos planos de aplicación del bitmap; 
uno vertical, siguiendo el eje Z, y otro ho- 
rizontal, siguiendo el eje Y. Crearemos 
un nuevo modelo que será la unión de 
dos operaciones CSG; una diferencia y 
una intersección. Para ello emplearemos 
una pieza, a la que llamaremos escal5m, 
que será la antigua escalera. r 


En la p:'mera operación restaremos a 
AN 


escal5m una caja que dividirá la antigua 
escalera en dos bandas muy delgadas. 
Sobre estas bandas aplicaremos el ma- 
peado estándar a lo largo del eje Z. La 
siguiente Operación de la unión es una 
intersección sobre escal5m empleando 
una caja de idénticas dimensiones a la 
de la caja de la operación anterior. Sobre 


reenenacennnenos 


romonnanos 


esta última pieza resultante de la intersec- 
ción aplicaremos la misma textura rotada 
90 grados en el eje X (aplicación a lo lar- 
go del eje Y). Así pues la nueva escalera 
será idéntica en su forma a la antigua. di- 
ferenciándose tan sólo en que el bitmap 
está mejor colocado. Esta descripción 
puede resultar un tanto liosa pero el nuevo 
modelo sigue siendo muy sencillo ya que 
no es sino la unión de dos escaleras: una 
en la que se ha aplicado el mape- 
ado primitivo a lo largo de Z. y 
otra (el centro de la escalera) so- 
bre la que hemos cuidado la apli- 
cación en las superficies horizon- 
tales de la escalera. 

El resultado es superior al de 
la escalera inicial de la cual se 
ha partido pero aún está lejos de 
ser perfecto. Para empezar : 
hemos cuidado la aplicación en 
el lado trasero de la escalera y en 
los lados verticales de los pelda- 
ños. Esto podría ser remediado 
rotando el plano de aplicación 
45 grados en el eje Z. Sin em- 
bargo el resultado —que pode- 
mos ver en la última escalera de 
la imagen= queda algo extraño. 
Ello se debe a que, al haber in- 
clinado el plano de aplicación, 
las piedras de la textura son más 
alargadas en los peldaños y la ci- 
ma, que en los laterales. 

Podríamos efectuar aún un 


¿ ¿huevo intento en el cual colocá- 


semos la textura en cada caja-peldaño 
de la escalera pero esto resultaría con- 
traproducente, puesto que el modelo 
resultante requeriría mucha más me- 
moria de cálculo que el antiguo. De he- 
cho, la escalera central de la imagen 
precisa también más memoria que la 
escalera inicial y por ello es adecuado 


guardar dos modelos: el antiguo se em- 
pleará en escenas “a vista de pajaro” 
donde la cámara abarque un amplio es- 
pacio y el nuevo en imágenes donde la 
cámara esté cerca de la escalera. Esta es 
la razon de que algunas líneas o bloques 
de sentencias estén englobadas por co- 
mentarios en los ficheros que compo- 
nen Castlib. ¡Hay que intentar ahorrar 
memoria de cálculo a toda costa! 


Una de las 
primeras pruebas 
de aplicación de 
los bitmaps. 
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“y 
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Más ejemplos 

Como hemos visto en el ejemplo an- 
terior, el uso de bitmaps puede afectar a 
la forma en que se construyen los obje- 
tos. Otro caso similar al anterior es el 
de las torres cuadradas, las cuales han 
debido construirse empleando 4 pane- 
les-caja en cada piso para evitar el efec- 
to de estiramiento. También sucede lo 
mismo con los objetos que hacen las 
veces de aspilleras en los muros y to- 
rres, con los cuales se ha usado un truco 
muy similar al descrito para la escale- 
ra. Hay, además, otras muchas piezas 
que han precisado alteraciones para que 
la aplicación del bitmap no resultase ca- 
tastrófica pero nada ha sido tan proble- 
mático como la creación de las piezas 


para las torres circulares. 


¿Deficiencia del POV? ¿Fallo 
del autor de castlib? 


2 Taller Virtual 


(o al menos éste parece ser el caso). Es- 
ta banda de envoltura va desde el punto 
0 al 1 del eje Y, por lo que el bitmap se 
repetirá cuantas veces sea preciso a lo 
largo de este eje hasta recubrir comple- 
tamente el objeto. 

Este es, en definitiva, el problema. 
ya que si se pretende crear una torre cu- 
yo diámetro sea de 10 ó 20 metros, pre- 
cisaremos que la banda de envoltura se 
repita bastantes veces en torno al cilin- 
dro, lo cual no parece estar contempla- 
do por POV. Podemos escalar la banda 
a lo largo del eje Y. pero. de cualquier 
modo, ésta se enrollará para cubrir una 
sola vez todo el cilindro. 


La chapuza 

Teniendo en cuenta esta extraña li- 
mitación del mapeado cilíndrico, el 
aplicar el bitmap a la torre se convirtió 
en una frustración para su autor. Final- 
mente, después de numerosas pruebas, 
se optó por una idea que solucionaba 
problema aunque, técnicamente 
ablando, se trata de una verdadera 
La pda consistía, lisa y ne 


l mapeado planar. Para ello, 
¿plear un cilindro para el 

la torre, se creó una nueva 
a es la del típico trozo 
al cortar en pedazos 


En fin, repasemos la teoría de l 
cación cilíndrica. En este tipo de n 


peado se asume que un cilindro 


cualquier diámetro se extiende a 101 
go del eje Y, quedando sus dos 


a cilíndrica. De esta 
indro empleado para la to- 
con la unión de varios 
este tipo, en cada uno de los 
plicó el bitmap usando la 
lanar. Cada uno de estos 
otó en torno al eje Y, hasta 
1r la forma del cilindro. 

ués de realizar varias pruebas 
rminó que construir el cilindro 
enos de 8 de estas piezas no era 


conveniente. Naturalmente a mayor nú- 
mero de trozos de tarta, menor era la 
curvatura de cada pieza con lo que la 
aplicación resultaba más perfecta. Los 
mejores resultados se obtuvieron con 
12 y 16 piezas por cilindro. (De nuevo 
aquí hay que hacer notar que esto re- 
quiere mucha más memoria que el em- 
pleo de un único cilindro pero...) 


Otros problemas 

Otro problema de difícil solución es 
el hecho de que un mismo bitmap pue- 
de dar diferentes resultados dependien- 
do de la distancia a la que enfoquemos 
el objeto sobre el que se efectúe la apli- 
cación. Un bitmap con ladrillos de dis- 
tintos colores puede quedar muy bien 
sobre la pared de una casa enfocada a 
corta distancia. Desde lejos, sin embar- 
go, puede suceder que los tonos se 
mezclen y obtengamos un resultado, 
cuanto menos. extraño. Por ello puede 
ser buena idea emplear alguna herra- 
mienta como Photoshop para obtener 
varjas versiones de la textura. 

Por último hay que resaltar un deta- 
lle de suma importancia. Podría pen- 
sarse que en la escena generada por 
POV la apariencia de los objetos sobre 
los que hemos aplicado la textura ha de 
quedar idéntica a la del bitmap origi- 
nal. Sin embargo esto no tiene por qué 
ser así. A menos que se le indique otra 
cosa, POV aplica un valor por defecto 
de 0.6 para diffuse, con lo que la textu- 
ra aplicada resultará un 40% más oscu- 
ra en la escena generada que en el bit- 
map. Para remediar esto basta con 
añadir un valor de 1 para diffuse. Esta 
sentencia especifica la cantidad de luz 
procedente de las fuentes que se refleja 
sobre el objeto. (Véanse las declaracio- 
nes de las texturas de muros en castlib). 


iblioteca 3D 


Esta sección, cuyo propósito es describir los pormenores del diseño de los 
modelos creados para Rendermanía, se inaugura hoy con el análisis de los 


modelos que componen la librería de formas medievales. 


a última versión de la li- 

brería de formas medie- 

vales llamada Castlib está 

compuesta por tres fiche- 

ros: Castle20.inc, town.inc 

y lateral.inc. Para utilizar 
Castlib, el usuario deberá crear un fi- 
chero.pov donde dispondrá convenien- 
temente cámara y luces y donde refe- 
renciará y situará los modelos de la 
librería. Únicamente será preciso sumar 
una sentencia HHinclude “castle20.inc” 
en el fichero .pov. (Castle20.inc ya tie- 
ne, a su vez, sentencias include para le- 
er town.inc o lateral.inc). Sin embargo, 
al renderizar cualquier escena, es proba- 
ble que el disco duro empiece a ronro- 
near y que, según sea el caso, el tiempo 
de parsing (preparación y compilación 
de la escena) se dispare. ¿Por qué? Al 
concluir la generación de la imagen, 
POV 3.0 exhibe una pantalla informati- 
va con diversos detalles de interés. En- 
tre estos se halla el apartado “Peak 
memory used”. Junto a él veremos una 
cifra que indica la cantidad total de me- 
moria empleada por POV para construir 
un modelo interno de la escena. Esta ci- 
fra puede referirse no sólo a la Ram si- 
no también, en caso de que nuestro or- 
denador no disponga de la suficiente 
memoria, a memoria virtual de disco 
duro. Naturalmente, cuanto más supere 
esta cifra al número de Megabytes de 
RAM del ordenador, más trabajo extra 
tendrá que hacer el disco duro. ¿Por qué 
ocurre esto? ¿Existe algún modo de re- 
ducir el consumo de memoria? 


Niveles de detalle y 
problemas 

Al proyectar Castlib, el objetivo de 
su creador era preparar escenas con 
castillos enormes compuestos por 
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multitud de to- 
rres, puentes y 
murallas de dis- 
tintas formas y 
Natu- 
ralmente, a fin de 
del 
tiempo suficiente 


tamaños. 
disponer 


para crear tantos 
objetos, ello im- 
plicaba que estas 
estructuras debían 
ser forzosamente 
bastante senci- 
llas. La idea era 
que las estructu- 
ras de mayor ta- 
maño se recarga- 
rían con otras de 
menores dimen- 
siones las cuales, 
a su vez, estarían 
rodeadas de otras 
de menor tama- 
ño. De esta ma- 
nera se confiaba 
en obtener casti- 
llos de una apa- 
rente compleji- 
dad a cambio de 
un mínimo €s- 
fuerzo en el modelado. Para reforzar 
esta impresión se dedicó más tiempo 
al modelado en detalle de los objetos 
pequeños; ventanas, puertas, aspille- 
ras, etc. De esta forma, al incluir estos 
objetos en la composición de las es- 
tructuras de mayor tamaño, estas ga- 
naban en realismo. Así pues puede ha- 
blarse de niveles en estos objetos; una 
ventana es un objeto de “bajo nivel”, 
una casa un objeto de un nivel mayor 
y un castillo o una ciudad tendrían el 
nivel más alto. 


Esta era. al menos. la idea inicial. 


No obstante, a medida que se iban 
agregando nuevos objetos a la libre- 
ría, algo iba quedando más y más cla- 
ro: aunque los ficheros ascii de Cas- 
tlib no ocupan demasiado, el modelo 
interno que POV prepara a partir de 
dichos ficheros si exige una cantidad 
de memoria considerable, -en el mo- 
mento de escribir estas líneas la sim- 
ple inclusión de castle20.inc, ya re- 
quería una peak memory de unos 55 
Megabytes—. Para ahorrar memoria y 


é 


por consiguiente ahorrar tiempo de 
cálculo, son recomendables las si- 
guientes medidas: 

-En primer lugar podemos hacer una 
copia de los ficheros originales. Hecho 
esto desactivaremos a todos aquellos 
objetos o estructuras que no vayan a 
participar en la escena. Esto podemos 
hacerlo marcándolos como comenta- 
rios (con “/*” y **P”), 

-En las pruebas intermedias pode- 
mos redefinir las texturas y usar un pig- 
mento simple. Al emplear un color en 


vez de un bitmap, 
ahorraremos mu- 
cha RAM, 

-St la escena va a 
prescindir de ca- 
sas y de estructu- 
ras laterales (para 
muros) y de algún 
elemento suelto, 
es conveniente 
prescindir de 
town.inc, para lo 
cual podemos eli- 
minar la corres- 
pondiente senten- 
cia Hinclude en 
castle20.inc. Esto 
permitirá ahorrar 
30 megabytes o 
más. Aunque, si 
el castillo va a 
emplear estructu- 
ras laterales y col- 
gantes, habrá que 
activar el include 
a lateral.inc. 


Como los objetos 
creados en POV 
no están com- 
puestos por polí- 
gonos resulta difícil estimar a priori la 
memoria que puede demandar un pro- 
yecto dado. Casi todos los modelado- 
res crean objetos a base de polígonos 
y suelen incluir herramientas para re- 
ducir el número de caras sin alterar 
excesivamente a los objetos. En POV 
esto (¡Ay!) no es posible. El único ca- 
mino es sustituir los objetos más com- 
plejos por otros más simples. Tenien- 
do esto en cuenta el autor de estas 
líneas probó a sustituir ciertos objetos 
complejos que se repiten mucho —las 


aspilleras, los marcos de puertas y 
ventanas— por otros más simples pe- 
ro, sorprendentemente, esto no aho- 
rró demasiada memoria dentro del 
conjunto. 


Composición de las torres 

Al realizar los primeros diseños ca- 
da torre se construía con un bloque 
propio de sentencias y tenía dimen- 
siones puestas a capricho. Esto pronto 
se reveló como algo ineficaz: las to- 
rres debían conectarse entre sí con 
murallas, debían existir escaleras para 
acceder a ellas y tenían que adornarse 
con otras estructuras de menor ta: 


ño —estructuras colgantes— para 
una mayor vistosidad. 
Pronto quedó patente. pu 
dimensiones debían ser nor 
Además, a fin de obtener mayor varie 
dad, cada torre no fue vida aisla 
damente. En lugar de e : creó una 
colección de seccion 
combinarse entre si para for 
de distinta altura y forma. 
Esta lista de seccio! 
varios grupos puesto 
crear torres de diferente 


tanas, torres colgantes y puertas (para 
acceder a las murallas). 

En cuanto a las secciones finales, 
todas tienen 5 metros de altura (mien- 


tras que las demás suelen tener 10 
metros de alto) y con ellas se constru- 
yen los techos de las torres. 


Los nombres de las secciones pare- 
cen bastante crípticos pero no ofrecen 
dificultades. Así “secb10_10r01” quie- 
re decir sección básica de tipo redondo 
(torres circulares), de 10 metros de diá- 
metro y 10 de alto y número 1. Otro 
ejemplo puede ser “secf20_5c02”, lo 
cual significa que se trata de una sección 
de tipo final y de forma cuadrada, con 
20 metros de diámetro y 5 de alto. El 
número 2 significa que podemos esco- 
ger entre varias secciones de este tipo 
para rematar nuestra torre. 

Todas las secciones están definidas 
de modo que descansan sobre el suelo, 
o sea que su base está en el punto O del 
eje Y. Veamos cómo crear una torre 
usando algunas de estas secciones: 


Hideclare TORRE25_10v=unionf 
object[secb10_10r] 
object[secm10_1Or translate<0,100,0>] 
object[secfl0_5rtranslate<0,200,0>] 


Esta torre tiene 25 metros de diáme- 
tro y forma circular. Al comienzo de 
cada sección hay un breve comentario 
indicando sus particularidades por lo 
que las tareas de construcción no debe- 
rían ser demasiado difíciles para los as- 
pirantes a maestro cantero. 

En cuanto al diseño de las secciones 
propiamente dichas, éste ha estado 
fuertemente determinado por el hecho 
de que se deseaba aplicar texturas bit- 
map. Por esta razón las secciones de 
las torres circulares son “trozos de 
pastel” y las secciones de las torres 
cuadradas están formadas por paredes 
similares a los paneles de las casas en 


Elementos en orden de 
complejidad creclente. 
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vez de por una única caja. Por último 
hay que señalar que todas las secciones 
están huecas y, cuando hay ventanas, 
tienen practicados los correspondientes 
agujeros de resta. Esto ha sido hecho 
así en previsión de que se prepare al- 
guna escena nocturna con fuentes de 
luz situadas dentro de las torres. (Ojo: 
las secciones, salvo las de cima, no tie- 
nen suelo ni techo). 


Estructuras 
de nivel medio 

Para que la apariencia de las torres 
y muros no resultase demasiado senci- 
lla se añadieron algunos modelos ex- 
tra. Este es el caso de las torres col- 
gantes y de las estructuras laterales. 


Las primeras son pequeñas torres de 
reducido tamaño adosadas a los muros 
laterales de las secciones medias. Las 
hay de forma circular y cuadrada y ca- 
recen de la portilla superior que tienen 
todas las torres normales. (Para acce- 


der a ellas, los habitantes del castillo 
deberán usar las puertas previstas para 
ello en la sección inmediatamente su- 
perior a la que incorpora estas estruc- 
turas). Las torres colgantes están pe- 
gadas a los muros por su centro de 
gravedad y tienen unos diez metros de 
alto. Dado que las puertas de acceso 
están colocadas en la sección de arriba 
no podemos colocar otra sección de 
torres colgantes encima; a menos que 
creemos una nueva sección con puer- 
tas y torres colgantes intercaladas. La 
excepción a esto son las estructuras 
“colgantes”. 

En cuanto a las estructuras laterales, 
son casas colocadas en town.inc y pen- 
sadas para adornar los muros interiores 
de los castillos. Realmente town.inc 
acabó convirtiéndose en una ciudad por 
culpa de estos adornos iniciales. Algu- 
nas de estas estructuras no pueden ser 
colocadas en los muros más bajos, de 
10 metros del alto. 


Detalles 
y carencias 

Cuando se diseñaron las aspilleras, 
las puertas, las ventanas, etc., se intentó 
tener en cuenta el tamaño de los posi- 
bles habitantes virtuales del castillo. 
Las aspilleras tienen una abertura inte- 
rior pensada para que los posibles ar- 
queros disparen al enemigo con como- 


didad y seguridad, las almenas tienen 
una anchura mínima adecuada para co- 
locar las puertas de las torres y para 
que se paseen por ellas los guerreros. 
Incluso se intentó que el tamaño de 
los peldaños en las escaleras no resul- 
tase excesivo para las sufridas piernas 


de nuestros guerreros virtuales. Como -: 
los personajes están centrados en el. 


eje Y y colocados a la altura del suelo 
resulta posible colocarlos fácilmente 
en cualquier punto del castillo (véanse 
las fotos). 

A pesar de todo, sin embargo, los es-- 
cenarios construidos a partir de castlib: 
son como decorados de cartón piedra; 
los pisos de las torres no tienen techos, 
ni suelos. ni. por supuesto. muebles. 
No existe tampoco una arquitectura in-. 
terna del castillo ni hay puente levadizo 
ni rastrillo ni las típicas escaleras de ca- 
racol. Es posible que en un futuro se 
añadan nuevos detalles pero. lo cierto 
es que las exigencias de memoria de 
POV pesan ya como una losa sobre es- 
te proyecto. 

Realmente es una pena que POV no 
tenga una sentencia equivalente al Grid 
del Polyray ya que, parece ser, esta sen- 
tencia coloca copias de objetos origi- 
nales sin más gasto que el necesario pa- 
ra indicar su posición. Por otro lado, 
Polyray carece de las nuevas sentencias 
de programación de POV 3.0. 


anntansaras 


Estructuras de mayor nivel 

En castlib realmente no se han defi- 
nido las estructuras de mayor nivel. 
Hay ejemplos de definiciones de to- 
Tres y, al final de castle20.inc, un 


ejemplo con un sio completo. Es- 
tos ejemplos, sin embargo, están mar- E 


cados como comentarios a fin de aho- 
rrar memoria. Ahora examinaremos el 
castillo. incluido “como ejemplo para 
estudiar la hlosofia a' la quedeben sg 


po nerse los constructores de castillos; 


Y: 


E 


3 torres son simples uniones de seccio- 
nes colocadas a distintas alturas. Con 


uña filosofía que debería ser válida: 
para cualquier proyecto arquitectónico. 
con POV. 

En el texto que define al castillo de 
nuestro ejemplo lo primero es la defi- 


nición de las torres simples que utili- $ 


zaremos para su edificación. Dichas 


dichas torres seguidamente se definen. 


: las nuevas uniones que forman los dos 


grupos de torres, utilizados en el ejem- 
_ plo. El primer grupo, amado torbala, 
es el empleado para adornar la estruc- 
tura principal del cagtillo (llamada 
body50_35). El-objeto principal de 
torbala es una torre redonda de 20 me- 
tros de ancho por 35 de alto. A pesar 
de sus torrecillas colgantes, esta torre 
resultaría excesivamente sencilla de 
no estar rodeada por otras 8 torres re- 


dondas y cuadradas de 25 y 15 metros 


de altura que se intercalan entre si. La 
idea inicial era recargar también a es- 
tas torres secundarias con estructuras 
colgantes pero el resultado era de un 
recargamiento excesivo por lo que al 


3 final se prescindió de estos objetos. 


- El cuerpo principal del castillo 
i —bodyS0_35- son 4 paredes que for- 


- man una caja de 50 metros de ancho y 


largo. por 40'metros de alto. En sus 4 
esquí as hay 4 grupos de torres torbala 
y en su parte superior otro grupo simi- 
lar de torres. Además se emplean 4 to- 


3 Tres centinelas de gran altura dispuestas 


entre los grupos laterales y la caja. 

A Para crear este castillo se estudió 
primero la altura que había de darse 
a cada torre para crear los grupos. 
Esto es necesario para impedir que 
algunas estructuras queden parcial- 
mente encajonadas entre otras; hay 
algunas torres que en realidad que- 
dan dentro de otras estructuras y no 
son visibles. 

Una vez creados los dos grupos y 
las torres principales únicamente hubo 
que colocar referencias a estas estruc- 
turas en los puntos adecuados del cuer- 
po principal. En el resultado se apre- 
cia una cierta falta de variedad, algo 
que podría haberse remediado en parte 
colocando algunas de las estructuras 
laterales de town.inc pero, a fin de 
ahorrar memoria, esto no se hizo. 

Durante las pruebas necesarias para 
construir este ejemplo también se veri- 
ficaron otros dos puntos. A saber, que 
resulta posible colocar casas (de 
town.inc) sobre estructuras de cas- 
tle20.inc con un buen resultado y que 
no hubiera sido mala idea diseñar unas 
torres cuadradas de aspecto “rústico” 
empleando algunos de los paneles usa- 
dos para las casas de town.inc. 
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¿ Código Pixels 


Di 
al 


Programación 


Los modelos arquitectónicos suelen estar construidos por muchos elementos 


que se repiten con frecuencia. Situar manualmente en una escena cada uno de 
estos elementos podría ser algo muy tedioso, ya que por ejemplo un castillo 
puede constar de cientos de estos elementos. Afortunadamente POV 3.0 


parece especialmente diseñado para crear escenas de este tipo. 
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orientada a escena 


stas nuevas sentencias de POV guardan un 

fuerte parecido con otras de nombre simi- 

lar de lenguajes como BASIC o C. De he- 

cho el funcionamiento de los comentarios 

en el lenguaje escénico de POV es idénti- 

co al de C++ y los operadores utilizados 
para las sentencias ¿Hf y fhwhile son también muy parecidos a 
los de C++. Es de esperar que estas nuevas pov-sentencias 
cambien enormemente la forma de trabajo de los usuarios de 
POV y por ello, a pesar de que ya hemos hablado sobre ellas 
en alguna que otra ocasión, estudiaremos hoy algunos casos 
prácticos de su uso en la creación de escenas. 


Bucles 

La nueva sentencia while de POV 3.0 funciona exacta- 
mente como lo esperaría cualquier programador: haciendo 
que las líneas englobadas dentro del +twhile se repitan una y 
otra vez en un bucle mientras la condición del mismo resulte 
cierta. Veamos un ejemplo; 
unionf 

ttdeclare nalm=0 

twhile (nalm!=6) 
object (aspilleraGt translate<0,100,-31>rotate y*(nalm*60)) 
Hdeclare nalm=nalm+| 

ttend 

rotate y*30 

) 

En este ejemplo, tomado de castle20.inc, se crea úna unión 
de objetos usando +twhile. La condición del bucle está siem- 
pre enmarcada entre paréntesis, siguiendo al while, y las sen- 
tencias afectadas por el Hwhile son las que se hallan entre di- 
cha sentencia y la palabra ttend. Así. en el ejemplo anterior. si 
la condición es cierta, Pov interpretará las dos líneas que for- 
man el bucle. Después, al llegar a end, POV regresará al 
thwhile que marca el extremo inicial del bucle y volverá a con- 
siderar la condición. Si ésta sigue siendo cierta, las senten- 
cias del bucle volverán a interpretarse. De lo contrario POV 


abandonará el bucle saltando a la sentencia qu Htend 


(rotate y*30). 


Para comprender esto. el usuario de POV debe recordar que 
la sentencia fkdeclare permite asignar valores a variables y alte- 
rar dichos valores posteriormente. En el ejemplo, la ejecución 
del bucle depende del valor de la variable nalm. Este valor se 
inicializa a O antes de entrar en el bucle y va incrementándose 
en una unidad con cada pasada del mismo. Cuando el valor de 
la variable llega a 6, la condición es falsa y POV abandona el 
bucle. Ahora bien: ¿cómo se determina la verdad o falsedad de 
la condición del bucle? Pues de la misma manera que en C. O 
sea: el valor cero es falso y cualquier otro es verdadero. Aunque 
hay que precisar que valores sumamente pequeños y próximos 
a O pueden ser asumidos como falsos por POV. 

Para determinar la veracidad o falsedad de las condiciones, 
POV dispone del siguiente juego de operadores relacionales: 


(A<B) A es menor que B. 


(A<=B)  Aes menor o igual que B. 
(A=B) A es igual a B. 

(A!=B)  Aesdistinto de B. 

(A>B) A es mayor que B. 
(A>=B)  Aes mayor o igual que B. 


También podemos emplear operadores lógicos para escri- 
bir condiciones complejas. POV dispone de... 

(ASLB) And  Lacondición es cierta si A y B son ver- 
daderos (con valores diferentes a cero). 

(A1B) Or 
bos son verdaderos. 

Teniendo esto en cuenta, ahora podemos entender la condición 
del ejemplo anterior, a la que podemos traducir como “mientras 
nalm sea distinto de 6”. (Por tanto mientras la variable no alcance 
dicho valor, el bucle se cumplirá). De esto deducimos que el bucle 


La condición es cierta si Ao B o am- 


del ejemplo sirve para crear una unión de 6 objetos aspilleraGt. 
Además el valor de la variable empleada para controlar el núme- 
ro de pasos del bucle nos sirve también para preparar la orienta- 
ción de cada objeto gracias a la sentencia “rotate y*(nalm*60)”. 
Ahora veamos algunos ejemplos más de condiciones. 
((A<B) 8: (A>=C)) 
mayor o igual que C, la condición es cierta 
00)! (A=C)) Si A * 500 es igual a 
C, la condición es cierta. 


Si A es menor que B y 
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Aparte de todo esto, POV emplea también operadores para 
trabajar con vectores y expresiones como *?” cuyo estudio 
dejaremos para otro día. Por ahora lo que sabemos ya resulta 
suficiente para empezar a hacer experimentos. 


¡A mí la guardia! 
Entre los ejemplos preparados para el presente número, el 
más interesante es el de la generación de ciudades medievales 
sin embargo comenzaremos por algo más sencillo: la coloca- 
ción de grupos de lanceros virtuales. Ni que decir tiene que 
tendremos que ser bastante modestos en cuanto al número de 
personajes a emplear en cada escena (a causa del con- 
sumo de memoria). Además por ahora ha- 
bremos de conformarnos con las dos 
únicas poses del lancero. Co- 
menzaremos estudiando la 
escena del desfile de la sec- 
ción “Cómo...”. En esta 
escena un pelotón de lan- 
ceros circula por las calles 
de una ciudad. Dicho pe- 
lotón se crea, en el fichero 
desfile.pov, con las sentencias 


Hdeclare fila) ¿declare columna=0 
tiwhile (fila<4) 
ttdeclare columna=0 
Hwhile (columna<2) 
object[lananda rotate y*-90 
translate<fila*-20.0.columna*15>) 
Htideclare columna=columna+l 
Htend 
Htdeclare fila=fila+1 
Htend 
Este bloque de sentencias utiliza un bucle ttwhile anidado 
dentro de otro. Veamos cómo interpreta POV todo esto. Los 
povmaniacos con conocimientos de programación pueden sal- 
tarse tranquilamente la siguiente explicación. En primer lugar 
se inicializarán a cero las variables de control de ambos bucles 
y se comprobará la condición del ttwhile más exterior. Al cum- 
plirse ésta se pasará a la siguiente sentencia, otra ftwhile, cuya 
condición también se cumplirá. Entonces se colocará un lan- 
cero andando (lananda) en las coordenadas X=fila*-20 y 
Z=columna*15. O sea en la posición <0,0> ya que las varia- 
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Colocación rand sobre 
un espacio ilimitado. 


Código £ Pixels 


bles fila y columna están con valor cero al llegar a esta refe- 
rencia al objeto lancero. Seguidamente se incrementa en uno 
la variable columna y el Htend nos devuelve nuevamente al 
while más interior. Aquí hay que recordar dos reglas. Pri- 
mera: cada fwhile debe cerrarse con un Htend. Segunda: en 
los bucles anidados el primer ttend corresponde al último 
Hwhile, el siguiente corresponde al siguiente fwhile más ex- 
terior y así sucesivamente. Pero sigamos con nuestro examen, 
la condición del while más interno volverá a examinarse y de 
nuevo se verificará su veracidad ya que la variable columna 
sigue siendo inferior a 2. Por ello POV colocará otro lancero 
cuya posición en X seguira siendo la misma, pues- 
to que fila sigue valiendo O, pero ahora 
su posición Z será igual a 15 dado 
que columna tiene el valor 1 
(columna*15). La variable 
columna volverá a incre- 
mentarse con lo que la 
siguiente vez ya no se 
cumplirá la condición 
del bucle interno y POV 
continuará con las senten- 
cias que siguen al primer 
Htend. En ellas se incrementará 
la variable fila y, al encontrar el 
ttend, POV saltara a la línea donde se halla 
el primer +while. Como la condición de dicho ttwhile sigue 
siendo cierta se ejecutarán las sentencias comprendidas den- 
tro del mismo. Así volverá a crearse un nuevo par de lanceros 
(esta vez en la posición X=-20) y nuevamente se incrementa- 
rá fila y se reinicializará columna. 

La ventaja que tiene este método anidado radica, por su- 
puesto, en que podríamos crear un pelotón mucho más nu- 
meroso o cambiar la forma del mismo simplemente modifi- 
cando las dos cifras de las condiciones de las sentencias 
Hwhile. También resulta muy fácil cambiar las distancias en- 
tre las filas o las columnas de lanceros cambiando los valores 
arbitrarios que hemos colocado dentro de “translate” para 
multiplicar la columna y fila de cada lancero. 


Guardando las torres 

Utilizando provechosamente las sentencias translate y ro- 
tate, y teniendo presentes las dimensiones de nuestros perso- 
najes y el área donde deben ser colocados, podemos situar 


Otra prueba aleatoria. 


fácilmente a estos en disposiciones más complejas que un sim- 


ple cuadro de lanceros desfilando. (Por supuesto un numeroso 
grupo de guerreros sería muy costoso en términos de memoria 
y por tanto de tiempo. pero el lector debe comprender que 
cuanto aquí se está exponiendo también puede ser aplicable a 
objetos menos gravosos). Podemos considerar muchos posi- 
bles ejemplos. Podríamos desear, por ejemplo, disponer un 
grupo de centinelas en una de las torres del castillo. Si dicha 
torre es redonda y tiene 20 metros de diámetro podríamos 
crear un grupo de 14 centinelas con las siguientes líneas 
declare nlan=0 
ttwhile (nlan<1 4) 
object[lananda translate<O,altura,-85> 
rotate y*(nlan*25.7)) 
ttdeclare nlan=nlan+1 

ttend 

Los 14 lanceros estarían todos situados cerca de las aspi- 
lleras de la torre a distancias equidistantes entre sí, y mirando 
hacia el exterior. Podriamos cambiar fácilmente el número o 
la colocación de los personajes pero hay un detalle que ya de- 
be estar empezando a fastidiar al povmaniaco; la excesiva re- 
gularidad en las formaciones creadas hasta ahora. Afortuna- 
damente POV 3.0 incorpora algunas nuevas características 
que nos permitirán solventar este problema. Entre ellas están 
las funciones para trabajar con vectores y con valores en flo- 
tante. Veamos algunas de ellas. 

Rand(A) Retorna el próximo número pseudoaleatorio del 
generador de idem, atendiendo al entero positivo A dado co- 
mo parámetro a la función. Previamente deberemos haber ini- 
cializado al generador con una llamada a la función seed(). 


Los números devueltos por rand() tienen valores compren- 
didos entre 0.0 y 1. Hay que recordar que estos valores no 
son verdaderamente aleatorios, sino que son el resultado de 
la aplicación de unas fórmulas. Esto quiere decir que para 
un código dado y una semilla elegida los valores devueltos 
serán siempre los mismos, lo cual es algo muy útil (luego 
veremos por qué). 

En cuanto a la función seed antes mencionada inicializa lo 
que el manual de POV llama un canal con E e e 


rá como semilla inicial para las fórmulas empleadas por el ge- 


. - Y o - Mi Ss 
nerador de números aleatorios. La función rand() a 4 Y 


> h 

mente nos devolverá un val icado como > 4 y” A 

parámetro. Esto quiere PD odemos abri canales "e 
en el generador para obtener las mismas secuencias de nume- ¿e 0 * 

ros, lo cual puede tener su utili Qu C 

. W 

= Pl >: 

a E 

siguiente trozo de cód + 


tídeclare R |=see 
tdeclare numla=( 
twhile (nunda<12) 


object(lanvigr translate< “alt a, 
3360) 


rand(R 1)*90> 


rotate y* rand 
ttdeclare la=nu 


da Z del guerrero y luego otro valo 
oscile entre O y 360 para la rotación en grados de eje Y. De 
esta manera, aunque los lance pre orientados mira 
do hacia afuera, su colocación será más rate ular. 
% q 2 e 
(Recordemos que el lancero está con los pies en Y=0, cen” 


trado en este eje, y mirando hacia -Z). Pa vir valores 
que oscilen entre O y 90 basta con multiplica 'ñ 


vuelto por rand() por 90. 

Si queremos que la pequeña guarnición de la torre tenga 
una disposición aún más irregular podemos empezar por co- 
locar otra rotación aleatoria de O a 360 antes de efectuar el 
translate. De esta manera los lanceros mirarán en todas di- 
recciones. Otra posible mejora puede consistir en emplear a 
rand() para decidir en cada pasada del bucle cuál de las dos 
posturas de lancero vamos a situar; si lananda o lanvigi. Para 
ello deberemos emplear una sentencia HHf. 
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Las sentencias +if y Felse 

La sentencia Hif es muy si- 
milar en su funcionamiento a 
Hwhile, aunque no implica bu- 
cle ninguno. Su estructura es: 

HHf (condición) 

bloque de sentencias 

Hend 

Cuando POV encuentra una 
sentencia Hif comprueba la vera- 
cidad o falsedad de la condición 
que le acompaña entre parénte- 


sis. Si esta es cierta, POV proce- 
de a interpretar el bloque de sen- 
tencias comprendidas entre el Hif 
y la sentencia Hend, De lo contra- 
rio salta a procesar las sentencias 


que siguen al Htend. Una senten- 
cia +Hf puede tener otras senten- 
cias ¿if incluidas dentro de su 
bloque de sentencias. Así. en las 
siguientes líneas..... 

HIf(A>B) 

Hif (A+15=C) 
object[lananda translate<12,50,0>] 
Hend 

Hideclare c=c+1 

Hend 

-..€l lancero se crearía sólo si las condiciones de ambos 
Htifs fueran ciertas. El segundo +tif sólo se consideraría si se 
cumple la condición del primero. En dicho caso, la variable e 
se incrementaría aunque el segundo +tif resultase falso ya que 
el tideclare con la Operación forma parte del bloque afectado 
por el primer +tif. (Cuando hay muchos Hifs o ttwhile, es pro- 
bable que el autor del codigo acabe por perder de vista las 
sentencias condicionales que controlan cada trozo de codigo 
y por ello es aconsejable atenerse a un sangrado en el texto). 
Por último, una sentencia Hif puede ir complementada con 
Htelse según el siguiente esquema: 

Hf (condición) 

bloque de sentencias 

ttelse 

bloque de sentencias 

Htend 
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Dos matrices de casas 
creadas con un doble 
bucle y dos valores de 
semilla distintos. 


Aquí, si la condición es cier- 


ta POV procesará el primer 
bloque de sentencias y, al 
llegar al Htelse, saltará a pro- 
cesar las sentencias que si- 
guen al Htend. Por el contra- 
rio, si la condición es falsa, 
se saltará directamente a 
procesar las sentencias que 
componen el segundo blo- 
que (después de lo cual se 
continuará con las siguientes 
al Htend). 
Ahora ya estamos en condi- 
ciones de reanudar el estudio 
del ejemplo anterior. Quería- 
mos usar la función rand() 
para decidir la colocación de una u otra postura del lancero 
para cada guerrero del grupo a crear. Para ello podríamos 
modificar el bloque de código del ejemplo de modo que que- 
dase así: 

Hideclare RI=seed(717) 

tídeclare numla=0 

Hwhile (numla<12) 

Hideclare cual=rand(R 1)*2 

Htifícual<l) 

object(lanvigi translate<O, altura, rand(R 1)*90> 
rotate y* rand(R1)*360) 
ttelse 
object(lananda translate<ó, altura, rand(R 1)*90> 
rotate y* rand(R1)*360] 

Hend 

declare numla=numla+1 
ttend 


ra “cual”, tendríamos que escribir un +if como el que sigue 
para representar la 3? postura: 

Hif((cual>2) él (cual<3)) 

object(postura3 ....) 

ttend 

Esto es engorroso y por ello lo mejor que podemos hacer es 
truncar la parte decimal que no necesitamos. De este modo el 
Htif anterior quedará como... 

HHf(cual=2) 

object[posturad3 ....] 

Htend 

Para truncar la parte decimal de un número flotante em- 
plearemos otra nueva función de POV 3.0; la función int(). En 
el ejemplo de las 4 posturas podríamos usarla así... 

declare cual=rand(R 1)*4 

declare cual=int(cual) 

..-O bien así... 

Hdeclare cual=int(rand(R 1)*4) 

Para la primera escena de esta sección 
las se ha creado con un bucle while y ut 
que la postura lanvigi tuviera una prob 
mayor que lananda. 

Al llegar a este punto seguro que 
estará empezando a imaginar posib 
binar rand() con +twhile.e +t1f. Cast 
desde la creación de un bosque a k 
una flota de naves espaciales o la 
guero. Sin embargo el empleo de r: 
tiene un pequeño problema. 


objetos se superpondrán en mayor o menor medida. Aqui 
hay que mencionar que es una pena que los señores del 
pov-team no hayan contemplado la posibilidad de que el 
usuario pueda crear arrays. Si POV 3.0 permitiera esto, 
bastaría con ir guardando los datos de posición de cada 
personaje en un elemento del array y compararlos para ca- 
da nuevo lancero a crear. 

Sin embargo, puesto que esto no es posible, veamos al- 
gunos trucos para optimizar el uso de rand(). Cuanto más 
densamente poblada vaya a a estar el área donde pensamos 


diseminar los modelos más posibilidades habrá de que dos o 
mas de ellos aparezcan superpuestos en la escena. Como la 
generación de la misma puede llevarse algún tiempo (sobre 
todo si los modelos son complejos), lo mejor es sustituir a 
los objetos por cajas de color con las mismas dimensiones 
de los personajes que aparecerán en la escena final. Tam- 
bién es conveniente eliminar al resto de los elementos de la 
escena y marcar el espacio donde los objetos deben disemi- 
narse. En las pruebas para la escena de los lanceros de la 
torre, cada pose del lancero fue sustituida por una caja de un 
color y el área circular del piso donde estos iban a ir, se mar- 
có con un cilindro de las mismas dimensiones del piso. De 
este modo las pruebas fueron bastante rápidas. 

En posteriores pruebas para este ejemplo se comprobó 
e el sitio donde más tendían a amontonarse los lanceros 


el centro de la torre. 
ara rebajar las proba- 


Una posible mane 
los personajes en la to 


sado para crear las ciu- 
Únicamente hay que crear un 
m de antes) para generar una ma- 
samos rand para decidir qué casa se va 
ar en cada punto dado de la matriz y, para evitar la su- 
perposición, añadimos un valor a la posición según las di- 
mensiones de cada casa. Este método, sin embargo, puede 
aún admitir muchas mejoras. Se podría cambiar la condición 
del bucle para que no tuviese en cuenta el número de casas de 
cada fila o columna, sino el largo de la calle. También se po- 
dría dar una distribución algo más aleatoria al trazado o em- 
plear una utilidad para adaptar las alturas de cada casa a los 
valores de una malla montañosa o... 
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2 La Portada 


Desde su puesto, en una estratégica torre, dos 


solitarios guerreros de doradas armaduras otean sin 


descanso el horizonte. A sus pies, sobre un acantilado, 


un enorme castillo se alza frente a un mar infinito. 


sto es, al menos, lo : 


que la portada de es- 


te número pretendía E 
representar. Desgra- a 
ciadamente, y por ¿ 
razones que ya se i 
han explicado, no ha sido posible guar- ¿ 
necer debidamente los muros de nuestro : 


castillo virtual. lo cual ha pesado bastan- 
te sobre el resultado que se buscaba. En 


efecto, utilizando las nuevas sentencias  ¿ 


de POV 3.0 no hubiese resultado difícil 


situar a cientos de lanceros sobre torres y E 
almenas... excepto por el hecho de que : 


habríamos necesitado cientos de me- 


gabytes de Ram para evitar el continuo E 


acceso de POV al disco duro. 


Posibles portadas 


Al crear una escena sintética el artista ¿ 
ha de materializar una posibilidad entre . 
un número infinito de opciones. Este a 
proceso es la primera dificultad con la a 
que debemos lidiar. Para empezar no es : 
raro que uno desee componer una escena ¿ 
a base de ideas o elementos que se ex- : 
cluyen mutuamente. Al cabo esto acaba : 
rebelándose como algo imposible y no S 
queda más remedio que empezar (¡ay!) a a 


tachar ideas de la lista. Por ello, a fin de 
sopesar las ventajas e inconvenientes de 
cada idea, lo mejor es empezar por reali- 
zar unos cuantos bocetos en papel. Así, 
para la portada del presente número, se 
prepararon varios bocetos iniciales. 

En el primer boceto el castillo se al- 
zaba sobre una solitaria y empinadísima 
montaña a la que sólo se podía acceder 
siguiendo un largo camino serpenteante. 
Esta es una ¡magen clásica que se ha 
usado infinidad de veces para ilustrar 
cuentos ¡gualmente clásicos pero que no 
por ello deja de resultar atractiva. En es- 
te dibujo el camino comenzaba casi a 
los pies de la cámara y se extendía dibu- 
jando numerosas curvas hasta llegar a 
las puertas del castillo situado casi al 
fondo de la imagen. El camino era es- 
trecho, con profundos precipicios a am- 
bos lados y la escena estaba dominada 
por las montañas. Como detalle adicio- 
nal, el dibujo incluía unos soldados si- 
tuados al principio del camino, de espal- 
das a la cámara y dirigiéndose al 
castillo. Esta idea presentaba diversos 
problemas. En el cuadro clásico el cas- 
tillo queda demasiado lejos de la cáma- 
ra -apenas es un borrón de tinta- con lo 


cual no resulta posible apreciar los de- 
talles. Este problema se agrava si inten- 
tamos ser fieles a la escena clásica en- 
focando el castillo desde abajo. 

Teniendo esto en cuenta se realizó 
un nuevo boceto en el que la cámara 
enfocaba al castillo desde arriba a una 
distancia muy inferior. Aquí todavía 
eran visibles algunas curvas del camino 
serpenteante pero ya no era posible te- 
ner en primer plano a los soldados. Se 
perdía el efecto del fondo montañoso 
y, por si esto fuera poco, se agravaban 
los problemas con el terreno (hablare- 
mos de estos problemas después). 

Desechadas las ideas iniciales se di- 
bujaron nuevos bocetos. En uno de 
ellos se representaba la típica ciudadela 
medieval: la cámara enfocaba en pri- 
mer plano la parte superior de los mu- 
ros de una ciudad. Tras las almenas, al- 
gunos soldados paseaban sobre la 
muralla y más allá, rodeada por la mu- 
ralla, se extendía una ciudadela en cuyo 
centro se alzaba un castillo. Esta idea 
tampoco duró mucho ya que nueva- 
mente el castillo quedaba demasiado 
alejado de la cámara y además ya se 
había usado una ciudad como portada 
del número O de Rendermanía. 

El siguiente boceto representaba al- 
gunos de los detalles de un castillo gi- 
gantesco. Toda la escena estaba llena 
de conjuntos de torres y murallas y no 
se veía suelo, ni cielo. Esta escena, que 
hubiera costado cara en memoria por 
su excesivo número de componentes, 
fue modificada lentamente hasta llegar 
al boceto final. En éste no se ve un cas- 


tillo completo pero la cámara está lo 
suficientemente alejada como para dar- 
nos una idea general de la estructura. 
Hay una torre centinela que sirve para 
colocar dos soldados en un punto don- 
de no restan espacio al protagonista del 
cuadro, el castillo. En cuanto a los pro- 
blemas con el terreno se han minimi- 
zado colocando la cámara en un punto 
desde el que es imposible ver la unión 
del castillo con el suelo. La textura del 
Heightfield es francamente mala (de 
hecho se reduce a un simple pigmento 
marrón) pero contrasta con el color me- 
dio de los bitmaps del castillo y con el 
color del agua empleada con el mismo 
fin (además se calcula rápidamente). 


Nuevos objetos para la 
portada 

Al optar por desarrollar la idea ante- 
rior se comenzó por hacer pruebas con 
el mismo castillo empleado como ejem- 
plo en el fichero castle20.inc. Los resul- 
tados, ño obstante, eran poco atractivos 
debido a la excesiva uniformidad de las 
estructuras empleadas. En principio se 
pensó en escribir nuevas grupos de to- 
rres para obtener una mayor variedad 
pero casi enseguida quedó claro que el 
mayor problema no estaba en la poca 
variación de estas estructuras, ni en el 
cambio de sus dimensiones, sino en la 
excesiva monotonía de la construcción 
resultante. Por esta razón se decidió 
construir un nuevo tipo de torre cuadra- 
da. Esta torre, de aspecto algo rústico, 
se construye con los mismos paneles y 
objetos empleados para el montaje de 
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<, La única diferencia estriba en junto de town.inc creado únicamente 


wos objetos son mucho más ¿ para ahorrar memoria). También se eli- 
chos o largos y en que el te- E minaron muchos de los elementos del 
escalado. Estas torres secre- ¿castillo que no iban a aparecer en la es- 
jones -como sucede con las cena final (aunque no todos ya que no 


diferencia está se conocía con precisión la distancia fi- 


¿ciones tienen 5 1 nal a que iba a dejarse la cámara). Esto 


to y en debe colocarse implica que el castillo no es en realidad 


final. Hay una construcción completa sino un de- 
corado de cartón piedra; algunas torres 
y estructuras no visibles fueron elimi- 
sobre las tí nadas, el muro que delimita el castillo 


matarlas o sólo existe en las zonas visibles de la 


rres colgar; na y hasta la torre donde van colo- 
3s los lanceros no es más que una 
-ión final que está flotando en el ai- 
Todo esto recuerda a una antigua 
novela de Dick llamada Ubik. En ella 


los humanos vagaban por un escenario 


¿omo en la port: 


virtual que abarcaba únicamente lo que 
iles de construir. podía alcanzar su capacidad de percep- 
- ¿Por qué malgastar memoria con 
tos no visibles?). Naturalmente no 
lríamos crear una animación cun es- 
niverso virtual incompleto pero si 
no pretendemos esto y no vamos a mo- 
ver demasiado la cámara... (Sin em- 
ras laterak bargo, y a pesar de todo lo dicho, la 


tes e cantidad de memoria requerida para 


pur erar nuestra portada es de algo más 
5 megabytes). 

| siguiente problema a considerar es 
Alel terreno. Existen muchas maneras 
de generar terrenos sobre los que colo- 
car nuestras construcciones virtuales. 
Podríamos, por ejemplo, emplear tools 
que generan ficheros con mallas de pai- 


- un gasto sajes fractales. (Algunas de estas herra- 


1, y dado que no mientas, como Frgen de Steve Anger, 
plearse casas sino tan ¿ generan archivos directamente legibles 
as laterales y colgantes, se por POV. En otros casos habrá que utili- 
include de “lateral.inc” en vez zar herramientas de conversión de for- 
orrespondiente a “town.inc”. (Re- matos). Sin embargo la mayoría de estos 


-ordemos que lateral.inc es un subcon- programas no nos permiten tener ningún 
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control sobre la forma final de la malla. 
Este detalle puede suponer un verdadero 
problema ya que la colocación de un 
castillo (o cualquier otro objeto) sobre 
un punto dado de una fractal requiere 
entonces un proceso de posicionamiento 
por tanteo (ya que no conocemos la al- 
tura del terreno en un punto dado y tam- 
bién puede ocurrir que la malla no dis- 
ponga de una meseta donde colocar 
nuestro objeto). El problema es aún ma- 
yor si queremos que parte del terreno se 
adapte a cierta forma (por ejemplo al ca- 
mino retorcido del primer boceto antes 
comentado). Afortunadamente estos 
problemas pueden ser soslayados em- 
pleando algun programa de dibujo 2D 
para “dibujar” el terreno sobre el que irá 
la construcción. 


Dibujando terrenos 

En esencia el proceso necesario para 
hacer esto es sencillo. Usando una he- 
rramienta de dibujo y procesado de 
imagen 2D -como por ejemplo Photos- 
hop- dibujaremos una imagen em- 
pleando una paleta de grises. En esta 
imagen los pixels negros corresponde- 
rán a los vértices de menor altura y los 
de blanco a los de mayor altura en la 
malla a generar. Para crear el bitmap 
usaremos las herramientas de que dis- 
ponga el programa que estemos usan- 
do; un generador de fractal de plasma 
(para crear la imagen inicial sobre la 
que vamos a trabajar), un “aerógrafo o 
un lápiz para crear las “mesetas” don- 
de irán los objetos y los caminos para 
llegar a dichas mesetas, etc. También 
podemos partir de una imagen dada a 
la que retocaremos. Una vez que ten- 
gamos la imagen tga, gif o png. la in- 
cluiremos como fuente para una sen- 
tencia height field de POV. Veremos 


Todas las 
pruebas 


intermedias se 
tiran sin 
texturas para 
agllizar ei 
render. 


entonces como las zonas con el blanco 
más intenso generan las zonas más al- 
tas de la malla. 

Para el primer boceto se preparó un 
bitmap con una única montaña remata- 
da por una gran meseta en la que se 
pensaba colocar el castillo. De dicha 
meseta (dibujada en el bitmap con el 
color blanco más intenso) partía una 
serpenteante línea blanca dibujada con 
“aerógrafo” de tal modo que sus bor- 
des quedaban difuminados. Esta línea 
era, por supuesto. el estrecho camino 
que se pretendía representar. Como los 
objetos height_field se extienden ini- 
cialmente sobre un área que abarca 
desde el punto <0,0,0> hasta el valor 1 
de todos los ejes, resulta posible deter- 
minar el punto exacto del objeto donde 
está el centro de la meseta en el bitmap. 
Para ello lo ideal es centrar el height- 
field en los ejes X y Z. Así, al escalar el 
objeto, seguiremos sabiendo dónde es- 
tá la meseta. (Basta con conocer la re- 


solución del bitmap y el valor X e Y 


donde se halla el centro de la meseta 


dentro de dicho bitmap). 

Nuestro posible control sobre la ma- 
lla montañosa resultante no es perfecto, 
aunque es fácil conseguir el efecto bus- 
cado de una manera aproximada. Para 
nuestro boceto, por ejemplo, se desea- 
ba que el camino serpenteante no tu- 
viese la misma altura en todos sus pun- 


tos y por ello se retocó la línea : 


serpenteante de modo que algunas zo- 
nas tuviesen distintos tonos de gris. El 
resultado, no obstante, no fue muy 
alentador ya que era difícil evitar que 
el camino obtenido en la malla presen- 
tase cambios de alturas abruptos. (Re- 
cordemos que, aunque POV puede re- 


presentar 65536 niveles de altitud, una E 


gama de grises dibujada con una utili- 
dad de dibujo sólo nos permitirá 256 
tonos de gris con los que, por tanto, só- 
lo podremos obtener 256 alturas dife- 
rentes desde POV). 


La portada escogida 

Para la imagen final, sin embargo, la 
malla montañosa no era estrictamente 
precisa puesto que la cámara no abarca 
al castillo completo y el único lado don- 
de podría verse tierra queda oculto tras 
un muro más alla del cual comienza 
nuestro mar virtual. Sin embargo -y por 
puro capricho- se decidió crear una ma- 
lla para dar algo más de realismo a la 
costa sobre la que se alza el castillo. Es- 
ta malla se creó empleando un método 
de POV bastante original (y que el autor 
de estas líneas descubrió en el manual 
de la nueva versión 3.0). En dicho méto- 
do POV se usa en primer lugar para 
construir un bitmap y luego, en la esce- 
na propiamente dicha, se da como en- 
trada este bitmap al heightfield. Aquí la 
única novedad radica en el primer paso, 
en la forma en que POV es usado para 
generar dicho bitmap: con la sentencia 
global_settings (usada para indicar pa- 
rámetros por defecto para muchas cosas 
distintas) se emplea la palabra hf_gray 
L6 para indicar que el fichero de salida 
usará un formato de 16 bits en escala de 
grises digerible por la sentencia 
height_field de POV (lo que nos dará 
65536 posibles valores de alturas). Lue- 
go se crea una cámara que enfoca un 
plano sobre el que va una textura que 
normalmente usa el patrón wrinkles 
(originalmente creado para generar apa- 
nencias de celofan o telas transparen- 
tes). El resultado puede verse en la malla 
parcialmente sumergida de la escena. 

En cuanto al mar, a fin de darle mayor 
luminosidad se creó una esfera celeste 
(aunque el cielo en si no es visible). Las 
texturas se retocaron para dar mayor con- 
traste a la portada y se generó la imagen a 
la resolución adecuada, lo que costó días 
al ordenador y sudores al usuario. 


Galería 
de Artistas 


Aquí tenéis una muestra de la paciencia, 
habilidad e imaginación que derrochan 
algunos autores que nos remiten sus trabajos. 
Como siempre en el CD recopilamos las obras 
de todos ellos y de los que por falta de espacio, 
que no de talento, no pueden estar aquí. 


omenzamos hablando de escaleras, Antonio 
C Ayala nos envía esta de caracol y con barandilla 

hecha con Moray (leed su carta en el foro). Ami- 
go Antonio, espero que estés satisfecho con la amplia- 
ción de Rendermanía (de la cual tú, con tus cartas eres 
uno de los culpables). Sin embargo aunque parezca in- 
creíble no tenemos hoy espacio para contestar a las cues- 
tiones que planteas y que tendrán que esperar a algún 
número próximo. Perdona y gracias por tus cartas pi- 
diendo la ampliación de Rendermanía. (Y que hicieron 
que me recordases a aquel romano que siempre acababa 
sus discursos diciendo “... Y hay que destruir Cartago”). 


2 qué decir de las magníficas es- 
cenas espaciales de Félix Hi- 
gueras Jorna? En ellas Felix 

reproduce el vuelo de la sonda espacial 
Voyager 2 por el sistema Solar. La son- 
da construida a partir de un dibujo de 
una revista es de un gran realismo y es- 
tá íntegramente creada con POV 3.0 
Ghwhile). Hay que hacer notar que los 
instrumentos de la sonda están 
articulados (+fif, rotate) y encuentro ver- 
daderamente admirable la escena de las 
nebulosas donde Félix ha empleado 
magistralmente los nuevos halos de 
POV 3.0. También hay que destacar 
otras escenas ¡igualmente extraordina- 
rias; unas latas de refresco y otras donde 
se mezcla sutilmente la imagen sintética 
de POV con fondos reales. En una esca- 
la de O a 10 anótate un 14. En resumen: 
ha nacido un nuevo POV-maestro. Las 
mejores pov-escenas que he visto en 
mucho, mucho tiempo. 


uestro amigo Juan Miguel Gonzá- 

lez Cortinas de Frio Software nos 

envía unas escenas construidas con 
modelos de 3D Studio que ha preparado ba- 
sándose en los caballeros sable de Bubble 
Gum Crisis, un popular manga del que tan só- 
lo cunozco “Demencia Mortal” de Adam 
Warren. Las chicas de Juan Miguel, aunque 
virtuales, son atractivas y están bien armadas. 
¡Ah, y echad un vistazo a su carta en el foro! 
En Frio Soft se buscan nuevos miembros. 
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esde Oviedo Carlos Fernández Alonso, nos envía una animación... de Mazinger Z. 

Carlos, a quien le parece increíble que Alberto Sendin se le adelantara en la idea, 

envía los archivos de generación de su animación y solicita una critica. Pues bien la 
animación -al igual que el Mazinger- está bastante bien, aunque debo confesar que me gustó 
más el trabajo de Alberto por dos razones: la primera porque su animación resultaba más di- 
námica que la tuya (la cámara se movía mejor) y por otro lado, Alberto modeló la base de Ma- 
zinger y eso siempre tiene más trabajo que incluir un bitmap detrás (aunque has tenido el 
acierto de alejar un poco el bitmap del fondo para que se aprecte algo de profundidad). Tam- 
bién es una pena que, ya que te molestaste en articular los puños, esto no se aprecie en la ani- 
mación. De todos modos, bien y adelante con tus siguientes animaciones. 


y FRIO 


Or 


Wa te 


avid Belinchón Domínguez nos ha enviado algunas de las esce- 

nas que pudo rescatar del desastre acaecido en su disco duro. Su 

escena principal no incluye archivos de generación pero la largí- 
sima explicación del proceso de modelado que adjunta en su carta de- 
muestra que la escena es suya. Así pues. por esta vez. incluyo aquí esta es- 
cena basada en la escalera de la Biblioteca Laurentina de la iglesia de San 
Lorenzo, en Florencia. Esta magnífica escalera virtual de David sólo di- 
fiere del original de Miguel Angel en el número de escalones. David envía 
sus felicitaciones a Socrates y sugiere la creación de un concurso de info- 
grafía arquitectonica. Respecto a esto. .. ¿Qué dicen los rendermaniacos? 
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magine 4.0 


Hace meses hablamos de un programa 
procedente del entorno Amiga. Se trataba 
de Imagine 2.0, un programa con el que 
resulta posible modelar, renderizar y animar 


complejos modelos 3d. Hoy incluimos en el CD las 


En el CD-Rom 


demos de la versión 4.0 (para DOS y Windows 95) 


de este magnífico programa. 


magine 4.0 presen- 
ta diferentes módu- 
los, cada uno de los 
cuales cumple una 
función concreta. 
Nos ofrece un edi- 
tor de formas, con el que resulta posible 
crear formas complejas utilizando lo 
que el programa llama secciones cruza- 
das, un editor de detalles. con el que po- 


dremos depurar los objetos creados en 


28 Rendermanía 


el módulo anterior utilizando una serie ; 
de poderosas funciones tales como E 
magnetismo, deformaciones varias (ta- ¿ 
per, bend, twist y otras), extrusiones, ¿ 
superficies de revolución, particulas, E 
blobs, etc. Desde este potente módulo ¿ 
podremos trabajar sobre el objeto como , 


tal o sobre sus caras o sus vértices. 


Otros módulos son el de preferencias, : 


usado para customizar el funcionamien- : 
to de Imagine, el editor de splines, usa- E 
do para crear objetos bidimensionales, E 
3 el editor de ciclos, empleado para traba- E 
E jar con animaciones, el editor de “sta- E 
E ges”, usado para potenciar la animación : 
y el editor de acciones usado conjunta- E 


mente con el anterior. 


Naturalmente, y dado que Imagine a 
es un programa comercial, lo que hoy : 
incluimos son demos utilizables de es- j 
te programa. Esto quiere decir que las : 
prestaciones de estas demos han sido E 
recortadas lo suficiente como para im- a 
pedir un uso comercial de las mismas, ¿ 
aunque sí podremos trastear con los : 
programas y tomar nota de sus caracte- . 
rísticas.La versión de DOS incluye el : 


" 
Ataicio iruagier DeL. dp 


a 


ma 


editor dé detalesImientras que la version 
de Windows95 ueluye el +Jorde detas: 
lles, el de Splines y.€l de stagesPor Com- 4; 
tra la versión de DOS no tiene las lismta- 
ciones de render de su hermana de 
Windows, la cual está restringida a 
320*240 pixels (aunque, eso sí, todas las 
escenas grabadas llevarán el nombre del 
programa y de la compañía). Con los 
programas vienen objetos de ejemplo 
que nos servirán para probar las funcio- 
nes disponibles. ¡Qué lo disfrutéis! 


NOTAS AMPORTANTE: 
1) Los bitmaps con los que han sido generadas lo 
mayoría do las imagenes ue son do libre distribu- 
ción. Por elto el lector habrá de sustituir les tex- 
turas que hay al principio do castle20.loc por 
etros bitmaps, por texturas procedurales e por 
pigmentos simplas. 
2) Si alguien so atreve a intentar renderizar la 
portada, que teme nota do pie ontes hay que 
renderizar la malla pare lo tierra do la misma 
(echad ue vistazo a portada.bat). 
ADVERTENCIA: Algunas de estas escenas (sobre 
todo la portada) requieren una gran contidad do 
memoria y son do muy lenta generación. 
DISCULPA: En el oñhmero 0 del magazine 
Rendermania ne fue poblicado el fichero town.Inc 
on el CD-ROM. Para renderizar las esceues de 
ese número incluimes la antigua versión de diche 
fichero on el directorie "anticua”. 


